Subject: Re: Capabilities SIGlet Kickoff

From: [email-masked] (Scott Barvick)
Date: Wed, 14 Jul 93 10:37:14 EDT

I like the proposed organization aspects of this siglet, and it seems
that we've jumped right into the technical work.  I'm starting to
see a few proposed capabilities (i.e. new features) flying around so
we might want to organize that process.  Are we trying to design
all of the new features for DLS (I don't think so) or are we trying
to put in place the mechanism by which new features developed in
other SIGlets are communicated?  It's something that we have to think about.
As we've already seen, getting an efficient, expandable mechanism
(UDP, TCP, GDS, ...) just to communicate capabilities will not be without 
differences of opinion. 

Of course, the difference between capabilities and the use of a remote
peer's capabilities as a feature is hard to separate.

As for the technical issues under discussion:

TCP vs. UDP
-  I think using another SSP message within TCP is the most convenient
   mechanism for getting the capabilities between peers.  A DLS switch
   could run in "Rev 1" mode until it receives the capabilities message.
   I would hope that receiving an unknown message type would not be fatal
   to anyone's implementation.

Vendor ID
-  Wayne mentioned the inclusion of vendor id and version number.   This
   is an interesting issue that I've gone back and forth about.  On one
   hand, I think we could all add value to communication between our 
   own implementations if this was available.  I think that is also the
   problem.  We might lose the incentive to be open about new features
   if we can tell our products from others.

Scott
[email-masked]

---

From: [email-masked]
Date: 14 Jul 93 11:53 EST

I think that it's important that we keep the capabilities
          exchange mechanism as simple as possible. Personally, I view
          it as a means to achieve demonstrable interoperability
          without having to wait for the rest of the spec to be fully
          developed.

          The question I have is what exactly is the unit of work for
          for this group? Is our goal to define only what is needed
          to maintain a session between two DLSw session partners
          or is it to list *all* capabilities about the DLSw engine -
          i.e. should the DLSw session partner know or care that
          in addition to the TRN connection across which they are
          currently conversing, the partner DLSw also has an SDLC
          port, a S/370 channel connection, and an Ethernet port?
          Maybe we could start by organizing a list of features that
          are candidates to be included in any capabilities exchange?

          Since I'm here, I'll also put forth my opinion that a)
          any work done on capabilities exchange should be self
          contained with DLSw itself - no external interfaces and b) I
          think its important that we all be able to recognize who it
          is we're talking to across that link via vendor id or some
          other mechanism.  First of all, there's a service and
          support issue to consider (maybe we should include the phone
          number of the person to call when stuff breaks in the
          exchange ;^) ) and secondly, I personally think providing
          value-added DLSw features specific to your particular
          platform (provided it doesn't get in the way of
          interoperability) is a positive thing for DLSw and
          encourages vendors to use the standard in place of their
          current crop of proprietary things (low level
          interoperability is better than no-level interoperability).

          Bill

 rom: [email-masked] (Scott Barvick)
Message-Id: <[email-masked]>
SMTP-CCMail translator Ver: acm 2.71 12/16/92
--------------------------------------------------------------------------------
I like the proposed organization aspects of this siglet, and it seems
that we've jumped right into the technical work.  I'm starting to
see a few proposed capabilities (i.e. new features) flying around so
we might want to organize that process.  Are we trying to design
all of the new features for DLS (I don't think so) or are we trying
to put in place the mechanism by which new features developed in
other SIGlets are communicated?  It's something that we have to think about.
As we've already seen, getting an efficient, expandable mechanism
(UDP, TCP, GDS, ...) just to communicate capabilities will not be without
differences of opinion.

TCP vs. UDP

Vendor ID

Scott
[email-masked]